IBIS Macromodel Task Group Meeting date: 15 March 2011 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Ansoft: Chris Herrick Danil Kirsanov Ansys: * Samuel Mertens Dan Dvorscak Deepak Ramaswamy Jianhua Gu Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: * Mike LaBonte Stephen Scearce Ashwin Vasudevan Ericsson: * Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Vladimir Dmitriev-Zdorov Zhen Mu * Arpad Muranyi Micron Technology: Randy Wolff Nokia-Siemens Networks: Eckhard Lenski Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Mike Steinberger Todd Westerhoff Snowbush IP: * Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: * Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Arpad: Ken has a new item for the agenda - Arpad welcome guest Marcus Van Iersell -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Bob check BIRD 127 for type clarification possibilities - In progress - Bob write a BIRD on correcting Table 1-3 in the spec. (Row 23). - In progress - Ambrish draft update BIRD for Table syntax - Arpad draft BIRD language for block size changes ------------- New Discussion: Crosstalk BIRD: - Arpad: A vote today was suggested last week - Arpad showed the BIRD - Radek: - On page 2 "The first column of the impulse matrix ..." is not right - It is not the primary channel, it is all through channels - Next paragraph "This implies ... written into the impulse matrix ..." - This is not right - Arpad: We should not vote today - Ken: There is nothing technically incorrect AR: Radek start email thread about Crosstalk BIRD issues GetWave block size: - Arpad showed the task list notes: - Item 8 "GetWave block size" - Now clarifies that segments need not be equally sized - Ambrish: I emailed privately last week on item 5 (Format Table) - Arpad: I will comment on that AR: Arpad submit BIRD 120 with new changes to the Open Forum Proposed Crosstalk BIRD changes: - Arpad showed a presentation from Snowbush and Sigrity - Ken: - Marcus developed an industry first AMI model with back-channel modeling - Have discovered what needs to change in AMI for back-channel - Back-channel is real time adaptive - Must be implemented in GetWave - Modifications: - Parameters both in and out - New reserved parameters - New back-channel .ami file format - Flow changes - Arpad: Is the new .ami file just additional - Ken: It is only for new data - Ken: - New reserved parameters - TrainEnable: on/off - Train: points to new .ami file - Frame: describes training bit stream - Max_Train_Bits: Max duration - BackChanControls: TX <-> RX variables - Back-channel AMI file follows AMI format - Has Reserved Parameters section - Scott: What seed is used for PRBS? - What sequence is used for PRBS taps? - Kumar: It depends on the standard - Another keyword may be required for LFSR - Ken: Maybe it should be under Data - Marcus: Naming the standard should eliminate the ambiguity - Fangyi: The Usage in Info - Can models use this? - Kumar: The model has to point to the file anyway - It will have the information - Fangyi: The file name is input to the model? - Kumar: Right - The EDA tool will only need part of it - Marcus: The parameter structure could be any AMI syntax - Fangyi: The EDA tool has to understand which params? - Marcus: The BC* back-channel controls - Kumar: The model has to know the entire standard - Ambrish: Fangyi wants to know if changing to Info will break it - Kumar: It won't break it - Marcus: Specifying the LFSR seed leaves nothing to the imagination - Arpad: It might be useful for overlaying - Ken: New BackChanControls section added - Marcus: This is a 3 tap control - It is implementation specific - 0, 1, -1 have meaning about tap saturation - Flow chart (page 11) shows TX and RX actions and decisions - Scott: What would be the back-channel flow with crosstalk present? - You could have a switch working during adaptation - Kumar: Crosstalk will corrupt the training pattern - Marcus: Only if it is correlated - Kumar: This is why the EDA tool generates the pattern - Arpad: So crosstalk is evaluated at each iteration? - Fangyi: Will crosstalk be evaluated simultaneously? - What if one channel is done training and not the other? - Marcus: Not a problem if the EDA tool knows what to do - Arpad: From where does the TX get the pattern for training? - Marcus: From the EDA tool - Arpad: So TX has to tell the tool when it is ready? - Kumar: IEEE gives the length of the pattern - The RX tells the tool when training is done - Marcus: The only TX GetWave change is modifying EQ based on parameters - Arpad: TX would have to remember the whole pattern - Kumar: The pattern has to be resent - Arpad: How will the tool know when to do that? - Walter: PRBS is infinitely long - Can only change tap coefficients on each GetWave call - How to tell tool how many bits to send - Marcus: 1000 bits should not be a problem - Walter: IP works with multiple standards - Will TX work with different RX protocols? - Marcus: TX and RX have to work together - IBIS would have to standardize this - Ken: We should keep back-channel discussions on the ibis-atm reflector - We should hash it out in these meetings before going to open forum - The presentation is on the ATM web page - Scott: This defines a GetWave training state - A state diagram would help - Arpad: Page 11 has something like that - Marcus: That shows only the training state - Kumar: When training done it goes seamlessly to normal mode - Scott: The exercise may show something we missed - Ambrish: Do we need two ami files? - Kumar: The TX and RX have to point to the same file - It is standard-specific, not model-specific - Arpad: Should a BIRD be started? - Ken: We should stick with PowerPoint for a while - Mike: There are new people on the new ibis-serdes-backchan list - It would be good to use both reflectors - Walter: Some of those people would not want to discuss generic AMI - Arpad: Agree that we should use both reflectors ------------- Next meeting: 22 Mar 2011 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives